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Abstract

   This document defines the "xml2rfc" version 2 vocabulary: an XML-
   based language used for writing RFCs and Internet-Drafts.

   Version 2 represents the state of the vocabulary (as implemented by
   several tools and as used by the RFC Editor) around 2014.

   This document obsoletes RFC 2629.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
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   Internet Architecture Board (IAB).  Documents approved for
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1.  Introduction

   This document describes version 2 ("v2") of the "xml2rfc" vocabulary:
   an XML-based language ("Extensible Markup Language" [XML]) used for
   writing RFCs [RFC7322] and Internet-Drafts [IDGUIDE].

   Version 2 represents the state of the vocabulary (as implemented by
   several tools and as used by the RFC Editor) around 2014.

   It obsoletes the original version ("v1") [RFC2629], which contained
   the original language definition and which was subsequently extended.
   Many of the changes leading to version 2 have been described in
   "Writing I-Ds and RFCs using XML (revised)" [V1rev], but that
   document has not been updated since 2008.

   Processing Instructions (Section 2.6 of [XML]) generally are specific
   to a given processor and thus are not considered to be part of the
   vocabulary.  See Section 4.1 of [TCLReadme] for a list of the
   Processing Instructions supported by the first implementation of an
   xml2rfc processor.

   Note that the vocabulary contains certain constructs that might not
   be used when generating the final text; however, they can provide
   useful data for other uses (such as index generation, populating a
   keyword database, or syntax checks).

1.1.  Syntax Notation

   The XML vocabulary here is defined in prose, based on the RELAX NG
   schema [RNC] contained in Appendix C (specified in RELAX NG Compact
   Notation (RNC)).

   Note that the schema can be used for automated validity checks, but
   certain constraints are only described in prose (example: the
   conditionally required presence of the "abbrev" attribute).
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2.  Elements

   The sections below describe all elements and their attributes.

   Note that attributes not labeled "mandatory" are optional.

   Except inside <artwork>, horizontal whitespace and line breaks are
   collapsed into a single whitespace, and leading and trailing
   whitespace is trimmed off.

2.1.  <abstract>

   Contains the Abstract of the document.  The Abstract ought to be
   self-contained and thus should not contain references or unexpanded
   abbreviations.  See Section 4.3 of [RFC7322] for more information.

   This element appears as a child element of <front> (Section 2.19).

   Content model:

   One or more <t> elements (Section 2.38)

2.2.  <address>

   Provides address information for the author.

   This element appears as a child element of <author> (Section 2.6).

   Content model:

   In this order:

   1.  One optional <postal> element (Section 2.27)

   2.  One optional <phone> element (Section 2.26)

   3.  One optional <facsimile> element (Section 2.16)

   4.  One optional <email> element (Section 2.14)

   5.  One optional <uri> element (Section 2.42)
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2.3.  <annotation>

   Provides additional prose augmenting a bibliographical reference.

   This element appears as a child element of <reference>
   (Section 2.30).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

2.4.  <area>

   Provides information about the IETF area to which this document
   relates (currently not used when generating documents).

   The value ought to be either the full name or the abbreviation of one
   of the IETF areas as listed on <https://www.ietf.org/iesg/area.html>.
   The list at the time that this document is being published is
   "Applications and Real-Time" ("art"), "General" ("gen"), "Internet"
   ("int"), "Operations and Management" ("ops"), "Routing" ("rtg"),
   "Security" ("sec"), and "Transport" ("tsv").

   Note that the set of IETF areas can change over time; for instance,
   "Applications and Real-Time" ("art") replaced "Applications" ("app")
   and "Real-time Applications and Infrastructure" ("rai") in 2015.

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.
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2.5.  <artwork>

   This element allows the inclusion of "artwork" in the document.

   <artwork> is the only element in the vocabulary that provides full
   control of horizontal whitespace and line breaks; thus, it is used
   for a variety of things, such as:

   o  diagrams ("line art"),

   o  source code,

   o  formal languages (such as ABNF [RFC5234] or the RNC notation used
      in this document),

   o  message flow diagrams,

   o  complex tables, or

   o  protocol unit diagrams.

   Note that processors differ in the handling of horizontal TAB
   characters (some expand them, some treat them as single spaces), and
   thus these ought to be avoided.

   Alternatively, the "src" attribute allows referencing an external
   graphics file, such as a bitmap or a vector drawing, using a URI
   ("Uniform Resource Identifier") [RFC3986].  In this case, the textual
   content acts as a fallback for output formats that do not support
   graphics; thus, it ought to contain either (1) a "line art" variant
   of the graphics or (2) prose that describes the included image in
   sufficient detail.  Note that RFCs occasionally are published with
   enhanced diagrams; [RFC5598] is a recent example of an RFC that was
   published along with a PDF with images.

   This element appears as a child element of <figure> (Section 2.17).

   Content model:

   Text
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2.5.1.  "align" Attribute

   Controls whether the artwork appears left justified (default),
   centered, or right justified.

   Allowed values:

   o  "left" (default)

   o  "center"

   o  "right"

2.5.2.  "alt" Attribute

   Alternative text description of the artwork (not just the caption).

2.5.3.  "height" Attribute

   The suggested height of the graphics (when it was included using the
   "src" attribute).

   This attribute is format dependent and ought to be avoided.

   When generating HTML output [HTML], current implementations copy the
   attribute "as is", thus effectively treating it as CSS (Cascading
   Style Sheets) pixels (see Section 4.3.2 of [CSS]).  For other output
   formats, it is usually ignored.

2.5.4.  "name" Attribute

   A filename suitable for the contents (such as for extraction to a
   local file).

   This attribute generally isn't used for document generation, but it
   can be helpful for other kinds of tools (such as automated syntax
   checkers, which work by extracting the source code).

2.5.5.  "src" Attribute

   The URI reference of a graphics file (Section 4.1 of [RFC3986]).

   Note that this can be a "data" URI [RFC2397] as well, in which case
   the graphics file is wholly part of the XML file.
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2.5.6.  "type" Attribute

   Specifies the type of the artwork.

   The value is either an Internet Media Type (see [RFC2046]) or a
   keyword (such as "abnf").  The set of recognized keywords varies
   across implementations.

   How it is used depends on context and application.  For instance, a
   formatter can attempt to syntax-highlight code in certain known
   languages.

2.5.7.  "width" Attribute

   The suggested width of the graphics (when it was included using the
   "src" attribute).

   This attribute is format dependent and ought to be avoided.

   When generating HTML output [HTML], current implementations copy the
   attribute "as is", thus effectively treating it as CSS pixels (see
   Section 4.3.2 of [CSS]).  For other output formats, it is usually
   ignored.

2.5.8.  "xml:space" Attribute

   Determines whitespace handling.

   "preserve" is both the default value and the only meaningful setting
   (because that's what the <artwork> element is for).

   See also Section 2.10 of [XML].

   Allowed values:

   o  "default"

   o  "preserve" (default)
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2.6.  <author>

   Provides information about a document's author.  This is used both
   for the document itself (at the beginning of the document) and for
   referenced documents (inside of <reference>).

   The <author> elements contained within the document's <front> element
   are used to fill the boilerplate, and also to generate the "Author's
   Address" section (see Section 4.12 of [RFC7322]).

   Note that an "author" can also be just an organization (by not
   specifying any of the name attributes, but adding the <organization>
   child element).

   Furthermore, the "role" attribute can be used to mark an author as
   "editor".  This is reflected on the front page and in the "Author's
   Address" section, as well as in bibliographical references.  Note
   that this specification does not define a precise meaning for the
   term "editor".

   See Sections 4.10 and 4.11 of [RFC7322] for more information.

   This element appears as a child element of <front> (Section 2.19).

   Content model:

   In this order:

   1.  One optional <organization> element (Section 2.25)

   2.  One optional <address> element (Section 2.2)

2.6.1.  "fullname" Attribute

   The full name (used in the automatically generated "Author's Address"
   section).

2.6.2.  "initials" Attribute

   An abbreviated variant of the given name(s), to be used in
   conjunction with the separately specified surname.  It usually
   appears on the front page, in footers, and in references.

   Some processors will post-process the value -- for instance, when it
   only contains a single letter (in which case they might add a
   trailing dot).  Relying on this kind of post-processing can lead to
   results varying across formatters and thus ought to be avoided.
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2.6.3.  "role" Attribute

   Specifies the role the author had in creating the document.

   Allowed values:

   o  "editor"

2.6.4.  "surname" Attribute

   The author's surname, to be used in conjunction with the separately
   specified initials.  It usually appears on the front page, in
   footers, and in references.

2.7.  <back>

   Contains the "back" part of the document: the references and
   appendices.  In <back>, <section> elements indicate appendices.

   This element appears as a child element of <rfc> (Section 2.33).

   Content model:

   In this order:

   1.  Optional <references> elements (Section 2.31)

   2.  Optional <section> elements (Section 2.34)
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2.8.  <c>

   Provides the content of a cell in a table.

   This element appears as a child element of <texttable>
   (Section 2.39).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

2.9.  <city>

   Gives the city name in a postal address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.10.  <code>

   Gives the postal region code.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.11.  <country>

   Gives the country in a postal address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.
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2.12.  <cref>

   Represents a comment.

   Comments can be used in a document while it is a work in progress.
   They usually appear (1) inline and visually highlighted, (2) at the
   end of the document (depending on file format and settings of the
   formatter), or (3) not at all (when generating an RFC).

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.12.1.  "anchor" Attribute

   Document-wide unique identifier for this comment.  The processor will
   autogenerate an identifier when none is given.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]),
   additionally constrained to US-ASCII characters [USASCII].

2.12.2.  "source" Attribute

   Holds the "source" of a comment, such as the name or the initials of
   the person who made the comment.
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2.13.  <date>

   Provides information about the publication date.

   Note that this element is used for the boilerplate of the document
   being produced, and also inside bibliographic references.

   In the "boilerplate" case, it defines the publication date, which,
   when producing Internet-Drafts, will be used for computing the
   expiration date (see Section 8 of [IDGUIDE]).  When one or more of
   "year", "month", or "day" are left out, the processor will attempt to
   use the current system date if the attributes that are present are
   consistent with that date.

   Note that in this case, month names need to match the full (English)
   month name ("January", "February", "March", "April", "May", "June",
   "July", "August", "September", "October", "November", or "December")
   in order for expiration calculations to work (some implementations
   might support additional formats, though).

   In the case of bibliographic references, the date information can
   have prose text for the month or year.  For example, vague dates
   (year="ca. 2000"), date ranges (year="2012-2013"), non-specific
   months (month="Second quarter") and so on are allowed.

   This element appears as a child element of <front> (Section 2.19).

   Content model: this element does not have any contents.

2.13.1.  "day" Attribute

   In the "boilerplate" case, the day of publication; this is a number.
   Otherwise, an indication of the publication day, with the format not
   being restricted.

2.13.2.  "month" Attribute

   In the "boilerplate" case, the month of publication; this is the
   English name of the month.  Otherwise, an indication of the
   publication month, with the format not being restricted.

2.13.3.  "year" Attribute

   In the "boilerplate" case, the year of publication; this is a number
   (usually four-digit).  Otherwise, an indication of the publication
   year, with the format not being restricted.
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2.14.  <email>

   Provides an email address.

   The value is expected to be an email address conforming to the
   addr-spec definition in Section 2 of [RFC6068] (so does not include
   the prefix "mailto:").

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.

2.15.  <eref>

   Represents an "external" link (as specified in the "target"
   attribute).

   If the element has no text content, the value of the "target"
   attribute will be inserted in angle brackets (as described in
   Appendix C of [RFC3986]) and, depending on the capabilities of the
   output format, hyperlinked.

   Otherwise, the text content will be used (and potentially
   hyperlinked).  Depending on output format and formatter, additional
   text might be inserted (such as a "URI" counter, and a "URIs" section
   in the back of the document).  Avoid this variant when consistent
   rendering across formats and formatters is desired.

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.15.1.  "target" Attribute (Mandatory)

   URI of the link target (see Section 3 of [RFC3986]).
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2.16.  <facsimile>

   Represents the phone number of a fax machine.

   The value is expected to be the scheme-specific part of a "tel" URI
   (so does not include the prefix "tel:"), using the "global numbers"
   syntax.  See Section 3 of [RFC3966] for details.

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.

2.17.  <figure>

   This element is used to represent a figure, consisting of an optional
   preamble, the actual figure, an optional postamble, and an optional
   title.

   This element appears as a child element of <section> (Section 2.34)
   and <t> (Section 2.38).

   Content model:

   In this order:

   1.  Optional <iref> elements (Section 2.20)

   2.  One optional <preamble> element (Section 2.29)

   3.  One <artwork> element (Section 2.5)

   4.  One optional <postamble> element (Section 2.28)

2.17.1.  "align" Attribute

   Used to change the alignment of <preamble> and <postamble>.

   Note: does not affect title or <artwork> alignment.

   Allowed values:

   o  "left" (default)

   o  "center"

   o  "right"
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2.17.2.  "alt" Attribute

   Duplicates functionality available on <artwork>; avoid it.

2.17.3.  "anchor" Attribute

   Document-wide unique identifier for this figure.

   Furthermore, the presence of this attribute causes the figure to be
   numbered.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.17.4.  "height" Attribute

   Duplicates functionality available on <artwork>; avoid it.

2.17.5.  "src" Attribute

   Duplicates functionality available on <artwork>; avoid it.

2.17.6.  "suppress-title" Attribute

   Figures that have an "anchor" attribute will automatically get an
   autogenerated title (such as "Figure 1"), even if the "title"
   attribute is absent.  Setting this attribute to "true" will prevent
   this.

   Allowed values:

   o  "true"

   o  "false" (default)

2.17.7.  "title" Attribute

   The title for the figure; this usually appears on a line after the
   figure.

2.17.8.  "width" Attribute

   Duplicates functionality available on <artwork>; avoid it.
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2.18.  <format>

   Provides a link to an additional format variant for a reference.

   Note that these additional links are neither used in published RFCs
   nor supported by all tools.  If the goal is to provide a single URI
   for a reference, the "target" attribute on <reference> can be used
   instead.

   This element appears as a child element of <reference>
   (Section 2.30).

   Content model: this element does not have any contents.

2.18.1.  "octets" Attribute

   Octet length of linked-to document.

2.18.2.  "target" Attribute

   URI of document.

2.18.3.  "type" Attribute (Mandatory)

   The type of the linked-to document, such as "TXT", "HTML", or "PDF".
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2.19.  <front>

   Represents the "front matter": metadata (such as author information),
   the Abstract, and additional notes.

   This element appears as a child element of <reference> (Section 2.30)
   and <rfc> (Section 2.33).

   Content model:

   In this order:

   1.  One <title> element (Section 2.40)

   2.  One or more <author> elements (Section 2.6)

   3.  One <date> element (Section 2.13)

   4.  Optional <area> elements (Section 2.4)

   5.  Optional <workgroup> elements (Section 2.44)

   6.  Optional <keyword> elements (Section 2.21)

   7.  One optional <abstract> element (Section 2.1)

   8.  Optional <note> elements (Section 2.24)
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2.20.  <iref>

   Provides terms for the document's index.

   Index entries can be either regular entries (when just the "item"
   attribute is given) or nested entries (by specifying "subitem" as
   well), grouped under a regular entry.

   In this document, for instance, every element definition appears as a
   regular index entry ("iref element 2.20").  In addition, for each use
   of that element inside another parent element, a nested entry was
   added ("iref element 2.20, ... inside annotation 2.3").

   Index entries generally refer to the exact place where the <iref>
   element occurred.  An exception is the occurrence as a child element
   of <section>, in which case the whole section is considered to be
   relevant for that index entry.  In some formats, index entries of
   this type might be displayed as ranges.

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <figure> (Section 2.17),
   <postamble> (Section 2.28), <preamble> (Section 2.29), <section>
   (Section 2.34), and <t> (Section 2.38).

   Content model: this element does not have any contents.

2.20.1.  "item" Attribute (Mandatory)

   The item to include.

2.20.2.  "primary" Attribute

   Setting this to "true" declares the occurrence as "primary", which
   might cause it to be highlighted in the index.

   Allowed values:

   o  "true"

   o  "false" (default)

2.20.3.  "subitem" Attribute

   The subitem to include.
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2.21.  <keyword>

   Specifies a keyword applicable to the document.

   Note that each element should only contain a single keyword; for
   multiple keywords, the element can simply be repeated.

   Keywords are used both in the RFC Index and in the metadata of
   generated documents.

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.

2.22.  <list>

   Delineates a text list.

   Each list item is represented by a <t> element.  The vocabulary
   currently does not directly support list items consisting of multiple
   paragraphs; if this is needed, <vspace> (Section 2.43) can be used as
   a workaround.

   This element appears as a child element of <t> (Section 2.38).

   Content model:

   One or more <t> elements (Section 2.38)

2.22.1.  "counter" Attribute

   This attribute holds a token that serves as an identifier for a
   counter.  The intended use is continuation of lists, where the
   counter will be incremented for every list item, and there is no way
   to reset the counter.

   Note that this attribute functions only when the "style" attribute is
   using the "format..." syntax (Section 2.22.3); otherwise, it is
   ignored.
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2.22.2.  "hangIndent" Attribute

   For list styles with potentially wide labels, this attribute can
   override the default indentation level, measured in number of
   characters.

   Note that it only affects styles with variable-width labels
   ("format..." and "hanging"; see below), and it may not affect formats
   in which the list item text appears _below_ the label.

2.22.3.  "style" Attribute

   This attribute is used to control the display of a list.

   The value of this attribute is inherited by any nested lists that do
   not have this attribute set.  It may be set to:

   "empty"

      For unlabeled list items; it can also be used for indentation
      purposes (this is the default value when there is an enclosing
      list where the style is specified).

   "hanging"

      For lists where the items are labeled with a piece of text.

      The label text is specified in the "hangText" attribute of the <t>
      element (Section 2.38.2).

   "letters"

      For ordered lists using letters as labels (lowercase letters
      followed by a period; after "z", it rolls over to a two-letter
      format).  For nested lists, processors usually flip between
      uppercase and lowercase.

   "numbers"

      For ordered lists using numbers as labels.

   "symbols"

      For unordered (bulleted) lists.

      The style of the bullets is chosen automatically by the processor
      (some implementations allow overriding the default using a
      Processing Instruction).
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   And finally:

   "format ..."

      For lists with customized labels, consisting of fixed text and an
      item counter in various formats.

      The value is a free-form text that allows counter values to be
      inserted using a "percent-letter" format.  For instance, "[REQ%d]"
      generates labels of the form "[REQ1]", where "%d" inserts the item
      number as a decimal number.

      The following formats are supported:

      %c lowercase letters (a, b, c, etc.)

      %C uppercase letters (A, B, C, etc.)

      %d decimal numbers (1, 2, 3, etc.)

      %i lowercase Roman numerals (i, ii, iii, etc.)

      %I uppercase Roman numerals (I, II, III, etc.)

      %% represents a percent sign

      Other formats are reserved for future use.

2.23.  <middle>

   Represents the main content of the document.

   This element appears as a child element of <rfc> (Section 2.33).

   Content model:

   One or more <section> elements (Section 2.34)
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2.24.  <note>

   Creates an unnumbered section that appears after the Abstract.

   It is usually used for additional information to reviewers (working
   group information, mailing list, ...), or for additional publication
   information such as "IESG Notes".

   This element appears as a child element of <front> (Section 2.19).

   Content model:

   One or more <t> elements (Section 2.38)

2.24.1.  "title" Attribute (Mandatory)

   The title of the note.

2.25.  <organization>

   Specifies the affiliation (Section 4.1.2 of [RFC7322]) of an author.

   This information appears both in the "Author's Address" section and
   on the front page (see Section 4.1.1 of [RFC7322] for more
   information).  If the value is long, an abbreviated variant can be
   specified in the "abbrev" attribute.

   This element appears as a child element of <author> (Section 2.6).

   Content model: only text content.

2.25.1.  "abbrev" Attribute

   Abbreviated variant.

2.26.  <phone>

   Represents a phone number.

   The value is expected to be the scheme-specific part of a "tel" URI
   (so does not include the prefix "tel:"), using the "global numbers"
   syntax.  See Section 3 of [RFC3966] for details.

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.
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2.27.  <postal>

   Contains child elements providing postal information.

   Note that at least one <street> element needs to be present; however,
   formatters will handle empty values just fine.

   This element appears as a child element of <address> (Section 2.2).

   Content model:

   In this order:

   1.  One or more <street> elements (Section 2.37)

   2.  In any order:

       *  <city> elements (Section 2.9)

       *  <region> elements (Section 2.32)

       *  <code> elements (Section 2.10)

       *  <country> elements (Section 2.11)

2.28.  <postamble>

   Gives text that appears at the bottom of a figure or table.

   This element appears as a child element of <figure> (Section 2.17)
   and <texttable> (Section 2.39).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)
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2.29.  <preamble>

   Gives text that appears at the top of a figure or table.

   This element appears as a child element of <figure> (Section 2.17)
   and <texttable> (Section 2.39).

   Content model:

   In any order:

   o  Text

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

2.30.  <reference>

   Represents a bibliographical reference.

   This element appears as a child element of <references>
   (Section 2.31).

   Content model:

   In this order:

   1.  One <front> element (Section 2.19)

   2.  Optional <seriesInfo> elements (Section 2.35)

   3.  Optional <format> elements (Section 2.18)

   4.  Optional <annotation> elements (Section 2.3)
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2.30.1.  "anchor" Attribute (Mandatory)

   Document-wide unique identifier for this reference.  Usually, this
   will be used both to "label" the reference in the "References"
   section, and as an identifier in links to this reference entry.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]),
   additionally constrained to US-ASCII characters [USASCII].  Thus, the
   character repertoire consists of "A-Z", "a-z", "0-9", "_", "-", ".",
   and ":", where "0-9", ".", and "-" are disallowed as start
   characters.

2.30.2.  "target" Attribute

   Holds the URI for the reference.

   Note that, depending on the <seriesInfo> element, a URI might not be
   needed and might not be desirable, as it can be automatically
   generated (for instance, for RFCs).

2.31.  <references>

   Contains a set of bibliographical references.

   In the early days of the RFC series, there was only one "References"
   section per RFC.  This convention was later changed to group
   references into two sets -- "Normative" and "Informative" -- as
   described in Section 4.8.6 of [RFC7322].  This vocabulary supports
   the split with the "title" attribute.

   By default, the order of references is significant.  Processors,
   however, can be instructed to sort them based on their anchor names.

   This element appears as a child element of <back> (Section 2.7).

   Content model:

   One or more <reference> elements (Section 2.30)

2.31.1.  "title" Attribute

   Provides the title for the "References" section (defaulting to
   "References").

   In general, the title should be either "Normative References" or
   "Informative References".
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2.32.  <region>

   Provides the region name in a postal address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.33.  <rfc>

   This is the root element of the xml2rfc vocabulary.

   Processors distinguish between RFC mode ("number" attribute being
   present) and Internet-Draft mode ("docName" attribute being present):
   it is invalid to specify both.  Setting neither "number" nor
   "docName" can be useful for producing other types of documents but is
   out of scope for this specification.

   Content model:

   In this order:

   1.  One <front> element (Section 2.19)

   2.  One <middle> element (Section 2.23)

   3.  One optional <back> element (Section 2.7)

2.33.1.  "category" Attribute

   Document category (see Appendix A.1).

   Allowed values:

   o  "std"

   o  "bcp"

   o  "info"

   o  "exp"

   o  "historic"
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2.33.2.  "consensus" Attribute

   Affects the generated boilerplate.

   See [RFC5741] for more information.

   Allowed values:

   o  "no"

   o  "yes"

2.33.3.  "docName" Attribute

   For Internet-Drafts, this specifies the draft name (which appears
   below the title).

   A processor should give an error if both the "docName" and "number"
   attributes are given in the <rfc> element.

   Note that the file extension is not part of the draft, so in general
   it should end with the current draft number ("-", plus two digits).

   Furthermore, it is good practice to disambiguate current editor
   copies from submitted drafts (for instance, by replacing the draft
   number with the string "latest").

   See Section 7 of [IDGUIDE] for further information.
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2.33.4.  "ipr" Attribute

   Represents the Intellectual Property status of the document.  See
   Appendix A.2 for details.

   Allowed values:

   o  "full2026"

   o  "noDerivativeWorks2026"

   o  "none"

   o  "full3667"

   o  "noModification3667"

   o  "noDerivatives3667"

   o  "full3978"

   o  "noModification3978"

   o  "noDerivatives3978"

   o  "trust200811"

   o  "noModificationTrust200811"

   o  "noDerivativesTrust200811"

   o  "trust200902"

   o  "noModificationTrust200902"

   o  "noDerivativesTrust200902"

   o  "pre5378Trust200902"

2.33.5.  "iprExtract" Attribute

   Identifies a single section within the document (by its "anchor"
   attribute) for which extraction "as is" is explicitly allowed (this
   is only relevant for historic values of the "ipr" attribute).
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2.33.6.  "number" Attribute

   The number of the RFC to be produced.

   A processor should give an error if both the "docName" and "number"
   attributes are given in the <rfc> element.

2.33.7.  "obsoletes" Attribute

   A comma-separated list of RFC _numbers_ or Internet-Draft names.

   Processors ought to parse the attribute value, so that incorrect
   references can be detected and, depending on output format,
   hyperlinks can be generated.  Also, the value ought to be reformatted
   to insert whitespace after each comma if not already present.

2.33.8.  "seriesNo" Attribute

   Number within a document series.

   The document series is defined by the "category" attribute;
   "seriesNo" is only applicable to the values "info" ("FYI" series),
   "std" ("STD" series), and "bcp" ("BCP" series).

2.33.9.  "submissionType" Attribute

   The document stream.

   See Section 2 of [RFC5741] for details.

   Allowed values:

   o  "IETF" (default)

   o  "IAB"

   o  "IRTF"

   o  "independent"

2.33.10.  "updates" Attribute

   A comma-separated list of RFC _numbers_ or Internet-Draft names.

   Processors ought to parse the attribute value, so that incorrect
   references can be detected and, depending on output format,
   hyperlinks can be generated.  Also, the value ought to be reformatted
   to insert whitespace after each comma if not already present.
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2.33.11.  "xml:lang" Attribute

   The natural language used in the document (defaults to "en").

   See Section 2.12 of [XML] for more information.

2.34.  <section>

   Represents a section (when inside a <middle> element) or an appendix
   (when inside a <back> element).

   Subsections are created by nesting <section> elements inside
   <section> elements.

   This element appears as a child element of <back> (Section 2.7),
   <middle> (Section 2.23), and <section> (Section 2.34).

   Content model:

   In this order:

   1.  In any order:

       *  <t> elements (Section 2.38)

       *  <figure> elements (Section 2.17)

       *  <texttable> elements (Section 2.39)

       *  <iref> elements (Section 2.20)

   2.  Optional <section> elements (Section 2.34)

2.34.1.  "anchor" Attribute

   Document-wide unique identifier for this section.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.34.2.  "title" Attribute (Mandatory)

   The title of the section.
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2.34.3.  "toc" Attribute

   Determines whether the section is included in the Table of Contents.

   The processor usually has defaults for whether a Table of Contents
   will be produced at all, and sections of which maximal depth will be
   included (frequently: 3).  "include" and "exclude" allow overriding
   the processor's default behavior for the element they are specified
   on (they do not affect either nested or parent elements).

   Allowed values:

   o  "include"

   o  "exclude"

   o  "default" (default)

2.35.  <seriesInfo>

   Specifies the document series in which this document appears, and
   also specifies an identifier within that series.

   This element appears as a child element of <reference>
   (Section 2.30).

   Content model: this element does not have any contents.

2.35.1.  "name" Attribute (Mandatory)

   The name of the series.

   Some series names might trigger specific processing (such as for
   autogenerating links, inserting descriptions such as "work in
   progress", or additional functionality like reference diagnostics).
   Examples for IETF-related series names are "BCP", "FYI",
   "Internet-Draft", "RFC", and "STD".

2.35.2.  "value" Attribute (Mandatory)

   The identifier within the series specified by the "name" attribute.

   For BCPs, FYIs, RFCs, and STDs, this is the number within the series.

   For Internet-Drafts, it is the full draft name (ending with the
   two-digit version number).
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2.36.  <spanx>

   Wraps a piece of text, indicating special formatting styles.

   When generating plain text, processors usually emulate font changes
   using characters such as "*" and "_".

   The following styles are defined:

   emph  Simple emphasis (this is the default).

   strong  Strong emphasis.

   verb  "Verbatim" text (usually displayed using a monospaced
      font face).

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.36.1.  "style" Attribute

   The style to be used (defaults to "emph").

2.36.2.  "xml:space" Attribute

   Determines whitespace handling.

   According to the DTD, the default value is "preserve".  However,
   tests show that it doesn't have any effect on processing; thus, this
   attribute will be removed in future versions of the vocabulary.

   See also Section 2.10 of [XML].

   Allowed values:

   o  "default"

   o  "preserve" (default)
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2.37.  <street>

   Provides a street address.

   This element appears as a child element of <postal> (Section 2.27).

   Content model: only text content.

2.38.  <t>

   Contains a paragraph of text.

   This element appears as a child element of <abstract> (Section 2.1),
   <list> (Section 2.22), <note> (Section 2.24), and <section>
   (Section 2.34).

   Content model:

   In any order:

   o  Text

   o  <list> elements (Section 2.22)

   o  <figure> elements (Section 2.17)

   o  <xref> elements (Section 2.45)

   o  <eref> elements (Section 2.15)

   o  <iref> elements (Section 2.20)

   o  <cref> elements (Section 2.12)

   o  <spanx> elements (Section 2.36)

   o  <vspace> elements (Section 2.43)

2.38.1.  "anchor" Attribute

   Document-wide unique identifier for this paragraph.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).

2.38.2.  "hangText" Attribute

   Holds the label ("hanging text") for items in lists using the
   "hanging" style (see Section 2.22.3).
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2.39.  <texttable>

   Contains a table, consisting of an optional preamble, a header line,
   rows, an optional postamble, and an optional title.

   The number of columns in the table is determined by the number of
   <ttcol> elements.  The number of rows in the table is determined by
   the number of <c> elements divided by the number of columns.  There
   is no requirement that the number of <c> elements be evenly divisible
   by the number of columns.

   This element appears as a child element of <section> (Section 2.34).

   Content model:

   In this order:

   1.  One optional <preamble> element (Section 2.29)

   2.  One or more <ttcol> elements (Section 2.41)

   3.  Optional <c> elements (Section 2.8)

   4.  One optional <postamble> element (Section 2.28)

2.39.1.  "align" Attribute

   Determines the horizontal alignment of the table.

   Allowed values:

   o  "left"

   o  "center" (default)

   o  "right"

2.39.2.  "anchor" Attribute

   Document-wide unique identifier for this table.

   Furthermore, the presence of this attribute causes the table to be
   numbered.

   The value needs to be a valid XML "Name" (Section 2.3 of [XML]).
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2.39.3.  "style" Attribute

   Selects which borders should be drawn, where

   o  "all" means borders around all table cells,

   o  "full" is like "all", except no horizontal lines between table
      rows (except below the column titles),

   o  "headers" adds just a separator between column titles and
      rows, and

   o  "none" means no borders at all.

   Allowed values:

   o  "all"

   o  "none"

   o  "headers"

   o  "full" (default)

2.39.4.  "suppress-title" Attribute

   Tables that have an "anchor" attribute will automatically get an
   autogenerated title (such as "Table 1"), even if the "title"
   attribute is absent.  Setting this attribute to "true" will
   prevent this.

   Allowed values:

   o  "true"

   o  "false" (default)

2.39.5.  "title" Attribute

   The title for the table; this usually appears on a line below the
   table body.
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2.40.  <title>

   Represents the document title.

   When this element appears in the <front> element of the current
   document, the title might also appear in page headers or footers.  If
   it's long (~40 characters), the "abbrev" attribute is used to specify
   an abbreviated variant.

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.

2.40.1.  "abbrev" Attribute

   Specifies an abbreviated variant of the document title.

2.41.  <ttcol>

   Contains a column heading in a table.

   This element appears as a child element of <texttable>
   (Section 2.39).

   Content model: only text content.

2.41.1.  "align" Attribute

   Determines the horizontal alignment within the table column.

   Allowed values:

   o  "left" (default)

   o  "center"

   o  "right"

2.41.2.  "width" Attribute

   The desired column width (as integer 0..100 followed by "%").
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2.42.  <uri>

   Contains a web address associated with the author.

   The contents should be a valid URI (see Section 3 of [RFC3986]).

   This element appears as a child element of <address> (Section 2.2).

   Content model: only text content.

2.43.  <vspace>

   This element can be used to force the inclusion of a single line
   break or multiple blank lines.

   Note that this is a purely presentational element; thus, its use
   ought to be avoided, except within a <list> as discussed in
   Section 2.22.

   This element appears as a child element of <t> (Section 2.38).

   Content model: this element does not have any contents.

2.43.1.  "blankLines" Attribute

   Number of blank lines to be inserted, where "0" indicates a single
   line break (defaults to "0").

   For paged output formats, no additional blank lines should be
   generated after a page break.

2.44.  <workgroup>

   This element is used to specify the Working Group (IETF) or Research
   Group (IRTF) from which the document originates, if any.  The
   recommended format is the official name of the Working Group (with
   some capitalization).

   In Internet-Drafts, this is used in the upper left corner of the
   boilerplate, replacing the default "Network Working Group" string.
   Formatting software can append the words "Working Group" or "Research
   Group", depending on the "submissionType" property of the <rfc>
   element (Section 2.33.9).

   This element appears as a child element of <front> (Section 2.19).

   Content model: only text content.
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2.45.  <xref>

   Inserts a cross-reference to a different part of a document.

   The generated text depends on (1) whether the <xref> is empty (in
   which case the processor will try to generate a meaningful text
   fragment), (2) the "format" attribute, and (3) the nature (XML
   element type) of the referenced document part.

   Any element that allows the "anchor" attribute can be referenced;
   however, there are restrictions with respect to the text content
   being generated.  For instance, a <t> can be a reference target;
   however, because paragraphs are not (visibly) numbered, the author
   will have to make sure that the combination of prose and contained
   text content is sufficient for a reader to understand what is being
   referred to.

   This element appears as a child element of <annotation>
   (Section 2.3), <c> (Section 2.8), <postamble> (Section 2.28),
   <preamble> (Section 2.29), and <t> (Section 2.38).

   Content model: only text content.

2.45.1.  "format" Attribute

   This attribute is used to control the format of the generated
   reference text.

   "counter"

      Inserts a counter, such as the number of a section, figure, table,
      or list item.

      For targets that are not inherently numbered, such as references
      or comments, it uses the anchor name instead.

   "default"

      Inserts a text fragment that describes the referenced part
      completely, such as "Section 2", "Table 4", or "[XML]".

   "none"

      There will be no autogenerated text.
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   "title"

      Inserts a title for the referenced element (usually obtained from
      the referenced element's "title" attribute; some processors also
      use the <title> child element or a <reference> target).

   Not all combinations of text content, "format" attribute, and type of
   referenced part lead to predictable results across different
   formatters.  In case this matters, the following combinations need to
   be avoided:

   o  Non-empty text content with any format other than "none".

   o  Empty text content with format "counter" for any target that isn't
      inherently numbered.

   o  Empty text content with format "title" for any target that doesn't
      have a title.

   Allowed values:

   o  "counter"

   o  "title"

   o  "none"

   o  "default" (default)

2.45.2.  "pageno" Attribute

   Unused.

   It's unclear what the purpose of this attribute is; processors seem
   to ignore it, and it never was documented.

   Allowed values:

   o  "true"

   o  "false" (default)

2.45.3.  "target" Attribute (Mandatory)

   Identifies the document component being referenced.

   The value needs to match the value of the "anchor" attribute of
   another element in the document.
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3.  Escaping for Use in XML

   Text in XML cannot use the literal characters "<" and "&", as they
   have special meaning to the XML processor (starting entities,
   elements, etc.).  Usually, these characters will need to be
   substituted by "&lt;" and "&amp;" (see Section 4.6 of [XML]).

   ">" does not require escaping, unless it appears in the sequence
   "]]>" (which indicates the end of a CDATA section; see below).

   Escaping the individual characters can be a lot of work (when done
   manually) and also messes up alignment in artwork.  Another approach
   to escaping is to use CDATA sections (Section 2.7 of [XML]).  Within
   these, no further escaping is needed, except when the "end-of-CDATA"
   marker needs to be used (in that case, the CDATA section needs to be
   closed, and a new one needs to be started).

4.  Special Unicode Code Points

   Although the current RFC format does not allow non-ASCII Unicode
   characters [UNICODE], some of them can be used to enforce certain
   behaviors of formatters.

   For instance:

   non-breaking space (U+00A0)

      Represents a space character where no line break should happen.
      This is frequently used in titles (by excluding certain space
      characters from the line-breaking algorithm, the processor will
      use the remaining whitespace occurrences for line breaks).

   non-breaking hyphen (U+2011)

      Similarly, this represents a hyphen character where no line
      breaking ought to occur.

   word joiner (U+2060)

      Also called "zero width non-breaking space" -- can be used to
      disallow line breaking between two non-whitespace characters.
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   Note that in order to use these characters by name, they need to be
   declared in either the Document Type Definition (DTD) or the
   "internal subset" (Section 2.8 of [XML]), like this:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- declare nbsp and friends -->
     <!ENTITY nbsp    "&#xa0;">
     <!ENTITY nbhy    "&#x2011;">
     <!ENTITY wj      "&#x2060;">
   ]>

5.  Including Files

   This version of the vocabulary does not support an inclusion
   mechanism on its own -- thus, a document always needs to be
   self-contained.

   That being said, some processors do support file inclusion using
   Processing Instructions (Section 2.6 of [XML] and Section 4.1.2 of
   [TCLReadme]).

   Furthermore, XML itself allows inclusion of external content using
   the "internal subset" (Section 2.8 of [XML]).  Unfortunately, this
   requires declaring the external data in the DTD upfront.

   For instance:

   <?xml version="1.0"?>

   <!DOCTYPE rfc [

     <!-- allow later RFC 2629 reference using "&rfc2629;" -->
     <!-- the data will be fetched from xml2rfc.ietf.org -->
     <!ENTITY rfc2629 PUBLIC
     "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
   ]>

   ...declares the entity "rfc2629", which then can be used in the
   "References" section:

     <references>
       &rfc2629;
     </references>
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   Note that this mechanism only works for well-formed XML fragments;
   thus, any plain text that would need to be escaped in XML can't be
   included as is.

6.  Internationalization Considerations

   This format is based on [XML] and thus does not have any issues
   representing arbitrary Unicode [UNICODE] characters in text content.

   However, the current canonical RFC format is restricted to US-ASCII
   characters (see [USASCII] and Section 3 of [RFC2223]).  It is
   possible that this rule will be relaxed in future revisions of the
   RFC format (for instance, to allow non-ASCII characters in examples
   and contact information).  In that case, it is expected that the
   vocabulary will be extended accordingly.

7.  Security Considerations

   The "name" attribute of the <artwork> element (Section 2.5.4) can be
   used to derive a filename for saving to a local file system.
   Trusting this kind of information without pre-processing is a known
   security risk; see Section 4.3 of [RFC6266] for more information.

   Furthermore, the nature of XML, plus vocabulary features such as
   typed artwork, make it attractive to extract content from documents
   for further processing, such as for the purpose of checking syntax or
   computing/verifying examples.  In the latter case, care needs to be
   taken that only trusted content is processed.

   All security considerations related to XML processing are relevant as
   well (see Section 7 of [RFC3470]).

8.  IANA Considerations

8.1.  Internet Media Type Registration

   IANA maintains the registry of Internet Media Types [BCP13] at
   <http://www.iana.org/assignments/media-types>.

   This document serves as the specification for the Internet Media Type
   "application/rfc+xml".  The following has been registered with IANA.

   Type name:  application

   Subtype name:  rfc+xml

   Required parameters:  There are no required parameters.
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   Optional parameters:  "charset": This parameter has identical
      semantics to the charset parameter of the "application/xml"
      Media Type specified in Section 9.1 of [RFC7303].

   Encoding considerations:  Identical to those of "application/xml" as
      described in Section 9.1 of [RFC7303].

   Security considerations:  As defined in Section 7.  In addition, as
      this media type uses the "+xml" convention, it inherits the
      security considerations described in Section 10 of [RFC7303].

   Interoperability considerations:  Some aspects of this vocabulary
      currently cannot be used interoperably; among the reasons for this
      are that they weren't precisely defined in the first place, that
      they have been added in an ad hoc fashion later on, or that they
      are specific to certain output formats.  This specification
      attempts to identify these cases in the description of the
      individual elements/attributes.

   Published specification:  This specification.

   Applications that use this media type:  Applications that transform
      xml2rfc to output formats such as plain text or HTML, plus
      additional analysis tools.

   Fragment identifier considerations:  The "anchor" attribute is used
      for assigning document-wide unique identifiers that can be used as
      shorthand pointers, as described in Section 3.2 of [XPOINTER].

   Additional information:

      Deprecated alias names for this type:  None.

      Magic number(s):  As specified for "application/xml" in
         Section 9.1 of [RFC7303].

      File extension(s):  .xml or .rfcxml when disambiguation from other
         XML files is needed.

      Macintosh file type code(s):  TEXT

   Person & email address to contact for further information:  See the
      Author's Address section of RFC 7749.

   Intended usage:  COMMON

   Restrictions on usage:  None.
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   Author:  See the Author's Address section of RFC 7749.

   Change controller:  RFC Series Editor (rse@rfc-editor.org)
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Appendix A.  Front-Page ("Boilerplate") Generation

A.1.  The "category" Attribute

   For RFCs, the "category" attribute (Section 2.33.1) determines the
   "maturity level" (see Section 4 of [RFC2026]).  The allowed values
   are "std" for "Standards Track", "bcp" for "BCP", "info" for
   "Informational", "exp" for "Experimental", and "historic" for
   "Historic".

   For Internet-Drafts, the "category" attribute is not needed; when
   supplied, it will appear as "Intended Status".  Supplying this
   information can be useful to reviewers.

A.2.  The "ipr" Attribute

   This attribute value can take a long list of values, each of which
   describes an IPR policy for the document (Section 2.33.4).  The
   values are not the result of a grand design, but they remain simply
   for historic reasons.  Of these values, only a few are currently in
   use; all others are supported by various tools for backwards
   compatibility with old source files.

      *Note:* some variations of the boilerplate are selected based on
      the document's date; therefore, it is important to specify the
      "year", "month", and "day" attributes of the <date> element when
      archiving the XML source of an Internet-Draft on the day of
      submission.

   _Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION.
   IF YOU NEED LEGAL ADVICE, PLEASE CONTACT A LAWYER._
   For further information, refer to
   <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>.

   For the current "Status of This Memo" text, the "submissionType"
   attribute (Section 2.33.9) determines whether a statement about "Code
   Components" is inserted (which is the case for the value "IETF",
   which is the default).  Other values, such as "independent", suppress
   this part of the text.
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A.2.1.  Current Values: "*trust200902"

   The name for these values refers to the IETF Trust's "Legal
   Provisions Relating to IETF Documents", sometimes simply called the
   "TLP", which went into effect on February 15, 2009 [TLP2.0].  Updates
   to this document were published on September 12, 2009 [TLP3.0] and on
   December 28, 2009 [TLP4.0], modifying the license for code components
   (see <http://trustee.ietf.org/license-info/> for further
   information).  The actual text is located in Section 6 ("Text to Be
   Included in IETF Documents") of these documents.

   Formatters will automatically produce the "correct" text, depending
   on the document's date information (see above):

   +----------+--------------------------------+
   | TLP      | starting with publication date |
   +----------+--------------------------------+
   | [TLP3.0] | 2009-11-01                     |
   | [TLP4.0] | 2010-04-01                     |
   +----------+--------------------------------+

      The TLP was again updated in March 2015 ([TLP5.0]), but the
      changes made in that version do not affect the boilerplate text.

A.2.1.1.  trust200902

   This value should be used unless one of the more specific
   "*trust200902" values is a better fit.  It produces the text in
   Sections 6.a and 6.b of the TLP.

A.2.1.2.  noModificationTrust200902

   This produces additional text from Section 6.c.i of the TLP:

      This document may not be modified, and derivative works of it may
      not be created, except to format it for publication as an RFC or
      to translate it into languages other than English.

      *Note:* this clause is incompatible with RFCs that are published
      on the Standards Track.
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A.2.1.3.  noDerivativesTrust200902

   This produces the additional text from Section 6.c.ii of the TLP:

      This document may not be modified, and derivative works of it may
      not be created, and it may not be published except as an
      Internet-Draft.

      *Note:* this clause is incompatible with RFCs.

A.2.1.4.  pre5378Trust200902

   This produces the additional text from Section 6.c.iii of the TLP,
   frequently called the "pre-5378 escape clause" (referring to changes
   introduced in [RFC5378]):

      This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English.

   See Section 4 of
   <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>
   for further information about when to use this value.

      *Note:* this text appears under "Copyright Notice", unless the
      document was published before November 2009, in which case it
      appears under "Status of This Memo".

A.2.2.  Historic Values

A.2.2.1.  Historic Values: "*trust200811"

   The attribute values "trust200811", "noModificationTrust200811", and
   "noDerivativesTrust200811" are similar to their "trust200902"
   counterparts, except that they use text specified in [TLP1.0].
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A.2.2.2.  Historic Values: "*3978"

   The attribute values "full3978", "noModification3978", and
   "noDerivatives3978" are similar to their counterparts above, except
   that they use text specified in Section 5 of [RFC3978].

A.2.2.3.  Historic Values: "*3667"

   The attribute values "full3667", "noModification3667", and
   "noDerivatives3667" are similar to their counterparts above, except
   that they use text specified in Section 5 of [RFC3667].

A.2.2.4.  Historic Values: "*2026"

   The attribute values "full2026" and "noDerivativeWorks2026" are
   similar to their counterparts above, except that they use text
   specified in Section 10 of [RFC2026].

   The special value "none" was also used back then; it denied the IETF
   any rights beyond publication as an Internet-Draft.
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A.3.  The "submissionType" Attribute

   The RFC Editor publishes documents from different document streams,
   of which the IETF stream is the most prominent.  Other streams are
   the independent stream (used for things such as discussion of
   Internet-related technologies that are not part of the IETF agenda),
   the IAB stream (Internet Architecture Board) and the IRTF stream
   (Internet Research Task Force).

   The values for the attribute are "IETF" (the default value),
   "independent", "IAB", and "IRTF".

   Historically, this attribute did not affect the final appearance of
   RFCs, except for subtle differences in copyright notices.  Nowadays
   (as of [RFC5741]), the stream name appears in the first line of the
   front page, and it also affects the text in the "Status of This Memo"
   section.

   For current documents, setting the "submissionType" attribute will
   have the following effect:

   o  For RFCs, the stream name appears in the upper left corner of the
      first page (in Internet-Drafts, this is either "Network Working
      Group" or the value of the <workgroup> element).

   o  For RFCs, it affects the whole "Status of This Memo" section (see
      Section 3.2.2 of [RFC5741]).

   o  For all RFCs and Internet-Drafts, it determines whether the
      "Copyright Notice" mentions the copyright on Code Components (see
      Section 6 of the TLP ("Text to Be Included in IETF Documents")).
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A.4.  The "consensus" Attribute

   For some of the publication streams (see Appendix A.3), the "Status
   of This Memo" section depends on whether there was a consensus to
   publish (again, see Section 3.2.2 of [RFC5741]).

   The "consensus" attribute ("yes"/"no", defaulting to "yes") can be
   used to supply this information.  The effect for the various
   streams is:

   o  "independent" and "IAB": none.

   o  "IETF": mention that there was an IETF consensus.

   o  "IRTF": mention that there was a research group consensus (where
      the name of the research group is extracted from the <workgroup>
      element).
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Appendix B.  Changes from RFC 2629 ("v1")

B.1.  Removed Elements

   The <appendix> element has been removed; to generate an appendix,
   place a <section> inside <back>.

B.2.  Changed Defaults

   Many attributes have lost their "default" value; this is to avoid
   having document semantics differ based on whether a DTD was specified
   and evaluated.  Processors will handle absent values the way the
   default value was specified before.
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B.3.  Changed Elements

   <artwork>: Has a set of new attributes: "name", "type", "src",
   "align", "alt", "width", and "height".  (Section 2.5)

   <author>: The <organization> element is now optional.  The "role"
   attribute was added.  (Section 2.6)

   <country>: The requirement to use ISO 3166 codes was removed.
   (Section 2.11)

   <date>: All attributes are now optional.  (Section 2.13)

   <figure>: Has a set of new attributes: "suppress-title", "src",
   "align", "alt", "width", and "height".  (Section 2.17)

   <iref>: Has a new "primary" attribute.  (Section 2.20)

   <list>: The "style" attribute isn't restricted to a set of enumerated
   values anymore.  The "hangIndent" and "counter" attributes have been
   added.  (Section 2.22)

   <reference>: <annotation> allows adding prose to a reference.  The
   "anchor" attribute has been made mandatory.  (Section 2.30)

   <references>: Can now appear multiple times and can carry a "title"
   attribute (so that normative and informative references can be
   split).  (Section 2.31)

   <rfc>: The "ipr" attribute has gained additional values.  The
   attributes "consensus", "iprExtract", "submissionType", and
   "xml:lang" have been added.  (Section 2.33)

   <section>: The new "toc" attribute controls whether it will appear in
   the Table Of Contents.  <iref> can now appear as a direct child
   element.  (Section 2.34)

   <t>: The "anchor" attribute can now be used as well; however, there
   are restrictions on how they can be referred to.  (Section 2.38)

B.4.  New Elements

   The following elements have been added: <annotation> (Section 2.3),
   <c> (Section 2.8), <cref> (Section 2.12), <format> (Section 2.18),
   <spanx> (Section 2.36), <texttable> (Section 2.39), and <ttcol>
   (Section 2.41).
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Appendix C.  RELAX NG Schema

   namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

   rfc =
     element rfc {
       attribute number { text }?,
       [ a:defaultValue = "" ] attribute obsoletes { text }?,
       [ a:defaultValue = "" ] attribute updates { text }?,
       attribute category {
         "std" | "bcp" | "info" | "exp" | "historic"
       }?,
       attribute consensus { "no" | "yes" }?,
       attribute seriesNo { text }?,
       attribute ipr {
         "full2026"
         | "noDerivativeWorks2026"
         | "none"
         | "full3667"
         | "noModification3667"
         | "noDerivatives3667"
         | "full3978"
         | "noModification3978"
         | "noDerivatives3978"
         | "trust200811"
         | "noModificationTrust200811"
         | "noDerivativesTrust200811"
         | "trust200902"
         | "noModificationTrust200902"
         | "noDerivativesTrust200902"
         | "pre5378Trust200902"
       }?,
       attribute iprExtract { xsd:IDREF }?,
       [ a:defaultValue = "IETF" ]
       attribute submissionType {
         "IETF" | "IAB" | "IRTF" | "independent"
       }?,
       attribute docName { text }?,
       [ a:defaultValue = "en" ] attribute xml:lang { text }?,
       front,
       middle,
       back?
     }








Reschke                       Informational                    [Page 58]

RFC 7749           The "xml2rfc" Version 2 Vocabulary      February 2016


   front =
     element front {
       title,
       author+,
       date,
       area*,
       workgroup*,
       keyword*,
       abstract?,
       note*
     }

   title =
     element title {
       attribute abbrev { text }?,
       text
     }

   author =
     element author {
       attribute initials { text }?,
       attribute surname { text }?,
       attribute fullname { text }?,
       attribute role { "editor" }?,
       organization?,
       address?
     }

   organization =
     element organization {
       attribute abbrev { text }?,
       text
     }

   address =
     element address { postal?, phone?, facsimile?, email?, uri? }

   postal =
     element postal { street+, (city | region | code | country)* }

   street = element street { text }

   city = element city { text }

   region = element region { text }

   code = element code { text }
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   country = element country { text }

   phone = element phone { text }

   facsimile = element facsimile { text }

   email = element email { text }

   uri = element uri { text }

   date =
     element date {
       attribute day { text }?,
       attribute month { text }?,
       attribute year { text }?,
       empty
     }

   area = element area { text }

   workgroup = element workgroup { text }

   keyword = element keyword { text }

   abstract = element abstract { t+ }

   note =
     element note {
       attribute title { text },
       t+
     }

   middle = element middle { section+ }

   section =
     element section {
       attribute anchor { xsd:ID }?,
       attribute title { text },
       [ a:defaultValue = "default" ]
       attribute toc { "include" | "exclude" | "default" }?,
       (t | figure | texttable | iref)*,
       section*
     }
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   t =
     element t {
       attribute anchor { xsd:ID }?,
       attribute hangText { text }?,
       (text
        | \list
        | figure
        | xref
        | eref
        | iref
        | cref
        | spanx
        | vspace)*
     }

   \list =
     element list {
       attribute style { text }?,
       attribute hangIndent { text }?,
       attribute counter { text }?,
       t+
     }

   xref =
     element xref {
       attribute target { xsd:IDREF },
       [ a:defaultValue = "false" ]
       attribute pageno { "true" | "false" }?,
       [ a:defaultValue = "default" ]
       attribute format { "counter" | "title" | "none" | "default" }?,
       text
     }

   eref =
     element eref {
       attribute target { text },
       text
     }

   iref =
     element iref {
       attribute item { text },
       [ a:defaultValue = "" ] attribute subitem { text }?,
       [ a:defaultValue = "false" ]
       attribute primary { "true" | "false" }?,
       empty
     }
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   cref =
     element cref {
       attribute anchor { xsd:ID }?,
       attribute source { text }?,
       text
     }

   spanx =
     element spanx {
       [ a:defaultValue = "preserve" ]
       attribute xml:space { "default" | "preserve" }?,
       [ a:defaultValue = "emph" ] attribute style { text }?,
       text
     }

   vspace =
     element vspace {
       [ a:defaultValue = "0" ] attribute blankLines { text }?,
       empty
     }

   figure =
     element figure {
       attribute anchor { xsd:ID }?,
       [ a:defaultValue = "" ] attribute title { text }?,
       [ a:defaultValue = "false" ]
       attribute suppress-title { "true" | "false" }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       iref*,
       preamble?,
       artwork,
       postamble?
     }

   preamble =
     element preamble { (text | xref | eref | iref | cref | spanx)* }
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   artwork =
     element artwork {
       [ a:defaultValue = "preserve" ]
       attribute xml:space { "default" | "preserve" }?,
       [ a:defaultValue = "" ] attribute name { text }?,
       [ a:defaultValue = "" ] attribute type { text }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       text*
     }

   postamble =
     element postamble { (text | xref | eref | iref | cref | spanx)* }

   texttable =
     element texttable {
       attribute anchor { xsd:ID }?,
       [ a:defaultValue = "" ] attribute title { text }?,
       [ a:defaultValue = "false" ]
       attribute suppress-title { "true" | "false" }?,
       [ a:defaultValue = "center" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "full" ]
       attribute style { "all" | "none" | "headers" | "full" }?,
       preamble?,
       ttcol+,
       c*,
       postamble?
     }

   ttcol =
     element ttcol {
       attribute width { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       text
     }

   c = element c { (text | xref | eref | iref | cref | spanx)* }

   back = element back { references*, section* }
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   references =
     element references {
       [ a:defaultValue = "References" ] attribute title { text }?,
       reference+
     }

   reference =
     element reference {
       attribute anchor { xsd:ID },
       attribute target { text }?,
       front,
       seriesInfo*,
       format*,
       annotation*
     }

   seriesInfo =
     element seriesInfo {
       attribute name { text },
       attribute value { text },
       empty
     }

   format =
     element format {
       attribute target { text }?,
       attribute type { text },
       attribute octets { text }?,
       empty
     }

   annotation =
     element annotation { (text | xref | eref | iref | cref | spanx)* }

   start = rfc

   (This schema was derived from version 1.3.6 of the xml2rfc DTD
   ("Document Type Definition") (Section 2.8 of [XML]), available from
   <http://svn.tools.ietf.org/svn/tools/xml2rfc/vocabulary/v2/03/
   xml2rfcv2.dtd>.)
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C.1.  Checking Validity

   The validity of XML files can be checked with any tool that supports
   RELAX NG [RNC].  The reference implementation is the Java-based,
   open-sourced "Jing" [JING].

   To use Jing, download the latest ZIP file from the "downloads" page
   (currently <https://code.google.com/p/jing-trang/downloads/
   detail?name=jing-20091111.zip>), extract the archive, copy "jing.jar"
   from the "bin" folder, and make sure Java is installed.

   To check a file "test.xml" using the RNC file "schema.rnc", run (from
   a command-line prompt):

   java -jar jing.jar -c schema.rnc test.xml

   In good Unix tradition, no output means the file is valid.
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